Mobile wireless device with protected file system

ABSTRACT

A mobile wireless device programmed with a file system which is partitioned into multiple root directories. The partitioning of the file system ‘cages’ processes as it prevents them from seeing any files they should not have access to. A Trusted Computing Base verifies whether or not a process has the required privileges or capabilities to access root sub-trees. The particular directory a file is placed into automatically determines its accessibility to different processes—i.e. a process can only access files in certain root directories. This is a light weight approach since there is no need for a process to interrogate an access control list associated with a file to determine its access rights over the file—the location of the file taken in conjunction with the access capabilities of a process intrinsically define the accessibility of the file to the process. Another aspect of this invention is that each process can have its own private area of the file system guaranteeing confidentiality and integrity to its data.

FIELD OF THE INVENTION

This invention relates to a mobile wireless device with a protected filesystem. The protected file system forms an element in a platformsecurity architecture.

DESCRIPTION OF THE PRIOR ART

Platform security covers the philosophy, architecture and implementationof platform defence mechanisms against malicious or badly written code.These defence mechanisms prevent such code from causing harm. Maliciouscode generally has two components: a payload mechanism that does thedamage and a propagation mechanism to help it spread. They are usuallyclassified as follows:

Trojan horse: poses as a legitimate application that appears benign andattractive to the user.

Worm: can replicate and spread without further manual action by theirperpetrators or users.

Virus: Infiltrates legitimate programs and alters or destroys data.

Security threats encompass (a) a potential breach of confidentiality,integrity or availability of services or data in the value chain andintegrity of services and (b) compromise of service function. Securitythreats are classified into the following categories:

1. Threats to confidentiality and integrity of data. Examples: Get userspassword; corrupt files.

2. Threats to confidentiality and integrity of services. Examples: Usebandwidth from phone network subscriber without paying for it; repudiatetransaction with network service provider.

3. Threats to availability of service (also called denial of service).Examples: Prevent the user from sending a text message; prevent the userfrom accepting a telephone call.

Hence, mobile wireless devices offer very considerable challenges to thedesigner of a security architecture. One critical aspect of thischallenge is to efficiently protect the file system to prevent maliciousapplications reading confidential data (e.g. PINs etc) and to preservethe integrity of the file system. To date, there have however been noefficient proposals for protecting the file system of a mobile wirelessdevice.

SUMMARY OF THE PRESENT INVENTION

In a first aspect of the present invention, there is a single usermobile wireless device programmed with a file system which ispartitioned into multiple root directories, in which the location of afile is enough to fully define its access policy to a process running onthe device (i.e. to define which processes can access the file). Thepartitioning of the file system in this way ‘cages’ processes as itprevents them from seeing any files they should not have access to.(Once a program containing native executable code is loaded in memory,it becomes a ‘process’; the process is therefore the running memoryimage of a program containing native executable code which is storedonto the file system). Trusted components, such as a ‘Trusted ComputingBase’ (which should be understood as covering architectural elementsthat cannot be subverted and that guarantee the integrity of the device;see Detailed Description section 1.1. for an implementation) verifywhether or not a process has the required privileges or ‘capabilities’(see Detailed Description at section 2 for an explanation of‘capabilities’) to access rood sub-trees (e.g. files in asub-directory).

As noted above, a secure operating system must control access to thefile system to ensure its own integrity, as well as user dataconfidentiality. With the present invention, a particular directory afile is places into automatically determines its accessibility todifferent process—i.e. a process can only access files in certain rootdirectories. This is a light weight approach since their is no need fora process to interrogate an access control list associated with a fileto determine its access rights over the file—the location of the filetaken in conjunction with the access capabilities of a processintrinsically define the accessibility of the file to the process.Moving the location of a file in the file system (e.g. between rootdirectories) can therefore modify the access policy of that file.

Each process may also have its own private area of the file systemguaranteeing confidentiality and integrity of its data.

With one of the possible implementations of the present invention(called implementation A in the rest of the document), a file is placedinto a location within a file system with 4 types of root directories(or their functional equivalents);

/system

/private/<process_secure_id>

/resources

/<others>

/system is accessible by any process that has been granted Rootoperating system privilege or capability (the concept of ‘capability’ isdiscussed in the Detailed Description section 2). Only processesassigned a ‘Root’ or ‘AllFiles’ capability can see files in the /systemsub-tree and only processes assigned Root can modify them

/private/<process_secure_id> is available to any processes having theirsecure identifier assigned to process secure_id, as well as processesthat have been granted ‘Root’ or ‘AllFiles’ capability. The SID (secureidentifier) of a process is a way of uniquely identifying a piece ofcode capable of running on the OS and is stored in the relatedexecutable. This executable is stored under/system and therefore cannotbe modified by processes without Root operating system privilege. When aprocess tries to access a file, the file system server will check itsSID and its privileges to decide to grant or deny access.

/resources is public read only; only the Trusted Computing Base TCB) canadd/remove/modify. The TCB comprises in one implementation the kernel,loader, file server and software installer.

/others> is available to any process for file read and write operations,file creation and deletion.

In another implementation, there is an ‘open’ mobile wireless deviceprogrammed with a software installer that is responsible for installingnew applications and their files without compromising the integrity ofthe existing file system. It would create or update files according totheir types, their location (public directories) and the secureidentifier (SID) of the programs (see Detailed Description at 3.3)

In another aspect, there is an operating system comprising a fileinstallation mechanism to allow programs to contribute to anotherprogram's private directory without compromising it (see DetailedDescription at 3.3)

DETAILED DESCRIPTION

The present invention will be described with reference to the securityarchitecture of the Symbian OS object oriented operating system,designed for single user wireless devices. The Symbian operating systemhas been developed for mobile wireless devices by Symbian Ltd, ofLondon, United Kingdom.

The basic outline of the Symbian OS security architecture is analogousto a medieval castle's defences. In a similar fashion, it employs simpleand staggered layers of security above and beyond the installationperimeter. The key threats that the model is trying to address are thosethat are linked with unauthorised access to user data and to systemservices, in particular the phone stack The phone stack is especiallyimportant in the context of a smart phone because it will be controllinga permanent data connection to the phone network There are two keydesign drivers lying behind the model:

Firewall protection of key system resources through the use ofcapability-based access control.

Data partitioning which creates a protected part of the file systemwhich standard software is not able to access.

The main concept of the capability model described below is to controlwhat a process can do rather than what a user can do. This approach isquite different to well-known operating systems as Widows NT and Unix.The main reasons are:

-   -   The very nature of Symbian OS is to be mono-user.

Symbian OS provides services through independent server processes. Theyalways run and are not attached to a user session. As long as power issupplied, Symbian OS is always on even if no user is logged on.

Symbian OS is aimed to be used in devices used by a large public with notechnology knowledge. When installing software, the user may not havethe skills to decide what permissions to grant to an application.Furthermore, with always-connected devices, the consequences of a wrongor malevolent decision may impact a domain much larger than the deviceitself.

1 Trusted Computing Platform

1.1 Trusted Computing Base

A trusted computing base (TCB) is a basic architectural requirement forrobust platform security. The trusted computing base consists of anumber of architectural elements that cannot be subverted and thatguarantee the integrity of the device. It is important to keep this baseas small as possible and to apply the principle of least privilege toensure system servers and applications do not have to be givenprivileges they do not need to function. On closed devices, the TCBconsists of the kernel, loader and file server; on open devices thesoftware installer is also required. All these processes are system-widetrusted and have therefore full access to the device file system. Thistrusted core would run with a “Root” capability not available to otherplatform code (see section 2.1).

There is one other important element to maintain the integrity of thetrusted computing base that is out of the scope of this invention,namely the hardware. In particular, with devices that hold trustedcomputing base functionality in flash ROM it is necessary to provide asecure boot loader to ensure that it is not possible to subvert thetrusted computing base with a malicious ROM image.

1.2 Trusted Computing Environment

Beyond the core, other system components would be granted restrictedorthogonal system capability and would constitute the Trusted ComputingEnvironment (TCE); they would include system servers such as socket,phone and window servers. For instance the window server would not begranted the capability of phone stack access and the phone server wouldnot be granted the capability of direct access to keyboard events. It isstrongly recommended to give as few system capabilities as possible to asoftware component to limit potential damage by any misuse of theseprivileges.

The TCB ensures the integrity of the full system as each element of theTCE ensures the integrity of one service. The TCE cannot exist without aTCB but the TCB can exist by itself to guarantee a safe “sand box” foreach process.

2 Process Capabilities

A capability can be thought of as an access token that corresponds to apermission to undertake a sensitive action. The purpose of thecapability model is to control access to sensitive system resources. Themost important resource that requires access control is the kernelexecutive itself and a system capability (see section 2.1) is requiredby a client to access certain functionality through the kernel API. Allother resources reside in user-side servers accessed via IPC [InterProcess Communication]. A small set of basic capabilities would bedefined to police specific client actions on the servers. For example,possession of a mike a capability would allow a client to use the phoneserver. It would be the responsibility of the corresponding server topolice client access to the resources that the capability represents.Capabilities would also be associated with each library DLL) and program(EXE) and combined by the loader at run time to produce net processcapabilities that would be held by the kernel. For open devices, thirdparty software would be assigned capabilities either during softwareinstallation based on the certificate used to sign their installationpackages or post software installation by the user. The policing ofcapabilities would be managed between the loader, the kernel andaffected servers but would be kernel-mediated through the IPC mechanism.

The key features of the process capability model are:

It is primarily focused around system servers and client-server IPCinteractions between these entities.

Capabilities are associated with processes and not threads. Threads inthe same process share the same address space and memory accesspermissions. This means that any data being used by one thread can beread and modified by all other threads in the same process.

The policing of the capabilities is managed by the loader and kernel andthrough capability policing at the target servers. The kernel IPCmechanism is involved in the latter.

When the code is not running, capabilities are stored inside oflibraries and programs. Capabilities stored in libraries and programsare not modifiable, as they would be stored during installation in alocation that is only accessible by the Trusted Computing Base.

Not all servers would have to handle client capabilities. Servers wouldbe responsible for interpreting capabilities as they wish.

The only cryptography involved in this scheme might be at the softwareinstallation stage where certificates would be checked off against asuitable root certificate.

2.1 System Capabilities: Protecting the Integrity of the Device

Root. “Full access to all files—Can modify capabilities associated withexecutables”

-   -   “Root” capability—Used by the Trusted Computing Base only, it        gives full access to all files in the device.        System Capabilities

Some system servers require some specific access to the TrustedComputing Base. Because of the object-oriented implementation of SymbianOS, the kind of resources required by a system server is most of thetime exclusive to it. Therefore, one system server would be granted somesystem capability that would be orthogonal to those required by another.For instance, the window server would be granted access to keyboard andpen events issued by the kernel but it would not have permission toaccess the phone stack In the same way, the phone server would begranted access to the phone stack but would not have permission tocollect events from the kernel. As examples, we can name:WriteSystemData Allows modification of configuration system data CommDDGrants access to all communication and Ethernet card device drivers.DiskAdmin Can perform administration task on the disk (reformat, renamea drive, . . . ).

2.2 User-Exposed Capabilities: Mapping Real-World Permissions

The process of generating capabilities can be difficult. One has firstto identify those accesses that require policing and then to map thoserequirements into something that is meaningful for a user. In addition,more capabilities means greater complexity and complexity is widelyrecognised as being the chief enemy of security. A solution based oncapabilities should therefore seek to minimise the overall numberdeployed. The following capabilities map fairly broadly onto the mainthreats which are unauthorised access to system services (eg. the phonestack) and preserving the confidentiality/integrity of user data.

PhoneNetwork. “Can access phone network services and potentially spenduser money”

-   -   “Make telephone calls”    -   “Send short text messages”.

WriteUserData. “Can read and modify users private information”

-   -   “Add a contact”.    -   “Delete an appointment”.

ReadUserData. “Can read users private information”

-   -   “Access contacts data”.    -   “Access agenda data”.

LocalNetwork. “Can access local network”

-   -   “Send Bluetooth messages”.    -   “Establish an IR connection”    -   “Establish an USB connection”

Location. “Can access the current location of the device”

-   -   “Locate the device on a map”    -   “Display closest restaurants and cinema”

Root and system capabilities are mandatory; if not granted to anexecutable, the user of the device cannot decide to do it. Their strictcontrol ensures the integrity of the Trusted Computing Platform. Howeverthe way servers check user-exposed capabilities or interpret them maybefully flexible and even user-discretionary.

2.3 Assigning Capabilities to a Process

The association of a run-time capability with a process involves theloader. In essence, it transforms the static capability settingsassociated with individual libraries and programs into a run-timecapability that the kernel holds and can be queried through a kerneluser library API.

The loader applies the following rules:

Rule 1. When creating a process from a program, the loader assigns thesame set of capabilities as its program's.

Rule 2. When loading a library within an executable, the librarycapability set must be greater than or equal to the capability set ofthe loading executable. If not true, the library is not loaded into theexecutable.

Rule 3. An executable can load a library with higher capabilities, butdoes not gain capabilities by doing so.

Rule 4. The loader refuses to load any executable not in the data cagedpart of the file system reserved to the TCB.

It has to be noted that:

Libraries' capabilities are checked at load time only. Beyond that, allcode contained in libraries is run freely and is assigned the samecapability set as the program it runs into when initiating some IPCcalls.

For ROM images with execution in place, the ROM build tool resolves allsymbols doing the same task as the loader at runtime. Therefore the ROMbuild tool must enforce the same rules as the loader when building a ROMimage.

These rules

Prevent malware from being loaded in sensitive processes, for example, aplug-in in a system server

Encourage encapsulation of sensitive code inside processes with nopossible bypass The examples below show how these rules are applied inthe cases of statically and dynamically loaded libraries respectively.

2.3.1 Examples for Linked DLLs

The program P.EXE is linked to the library L1.DLL.

The library L1.DLL is linked to the library L0.DLL.

Case 1:

-   -   P.EXE holds Cap1 & Cap2    -   L1.DLL holds Cap1 & Cap2 & Cap3    -   L0.DLL holds Cap1 & Cap2    -   Process P cannot be created, the loader fails it because L1.DLL        cannot load L0.DLL. Since L0.DLL does not have a capability set        greater than or equal to LL1DLL, Rule 2 applies.

Case 2:

-   -   P.EXE holds Cap1 &Cap2    -   L1.DLL holds Cap1& Cap2 & Cap3    -   L0.DLL holds Cap1 & Cap2 & Cap3 & Cap4    -   Process P is created, the loader succeeds it and the new process        is assigned Cap1 & Cap2. The capability of the new process is        determined by applying Rule 1; L1.DLL cannot acquire the Cap4        capability held by L0.DLL, and P1.EXE cannot acquire the Cap3        capability held by L1.DLL as defined by Rule 3.

2.3.2 Examples for Dynamically Loaded DLLs The program P.EXE dynamicallyloads the library L1.DLL. The library L1.DLL then dynamically loads thelibrary L0.DLL.

Case 1:

-   -   P.EXE holds Cap1 & Cap2    -   L1.DLL holds Cap1 & Cap2 & Cap3    -   L0.DLL holds Cap1 & Cap2    -   Process P is successfully created and assigned Cap1 & Cap2.    -   When P requests the loader to load L1.DLL & L0.DLL, the loader        succeeds it because P can load L1.DLL and L0.DLL. Rule 2 does        apply here the loading executable being the process P not the        library L1.DLL: the IPC load request that the loader processes        is sent by the process P. The fact that the call is within        L1.DLL is here irrelevant. Rule 1 & 3 apply as before and P does        not acquire Cap3 by loading L1.DLL

Case 2:

P.EXE holds Cap1 & Cap2

-   -   L1.DLL holds Cap1&Cap2&Cap3    -   L0.DLL holds Cap1&Cap2&Cap4    -   Process P is successfully created and assigned Cap1 & Cap2. When        P requests the loader to load L1.DLL & L0.DLL, the loader        succeeds it because P can load L1.DLL and L0.DLL. Once again,        Rule 2 does apply with P as the loading executable rather than        L1.DLL, while Rule 3 ensures P acquires neither Cap3 nor Cap4.

3 Caging processes

3.1 Location-based concept

Data partitioning involves separating code from data in the file systemsuch that a simple trusted path is created on the platform. The centralidea of the present invention is that by “caging” non-TCB processes intotheir own part of the file system, sensitive directories become hiddento them. In implementation A, the /system directory becomes hidden toordinary processes; the kernel and the file server would check that aclient process had Root or AllFiles capability before allowing anyaccess to the /system sub-tree. All other clients would have their ownrestricted view on the file system which would consist of the sub-treebelow a special private directory which would be /private/<app_SID>, /resources and /<others>. In addition, the loader would disallow anyattempt to execute code not residing in /system.

SIDs (Secure Identifiers) would be used to distinguish between thesub-tree directories. Applications for example would use their sub-treeto hold their own resource files. In essence, data partitioning involvescaging processes into their own small part of the file system. Thismeans that there is default protection of per-application and per-serverdata from other processes. Without partitioning, it would becomenecessary to introduce access control lists into the file system toprevent rogue programs bypassing the capability model and simply readingdatabases directly from files. In addition, the scheme affords furtherprotection against the threat of malicious replacement of systemplug-ins in the TCB reserved directory (/system in implementation A). Ananalogy may be made with memory management; currently only the kernelhas an unrestricted view of the real machine memory. Each process hasits own view of the processor's address space that is independent of allother processes. This is arranged and policed by the kernel and thememory management unit i; any access outside the range of one processmemory space is rejected.

In that sense, partitioning is a simple and robust solution:

-   -   The location of a file is sufficient to fully describe its        access rules. No extra information is required.    -   Its rules can be modified only if its location can be modified.    -   Each process is granted a private area, which guarantees        confidentiality and integrity of its data.

For simplicity the file system is not aware of the meaning of “privateuser data” and “system data”. A file cannot be flagged as so. It is theresponsibility of each server and application to manageReadUserData/WriteUserData and ReadSystemData/WriteSystemDatacapabilities when required. For example, if a user wants to identify aword processor document as private, she can password-protect it, makingReadUserData unnecessary to access the encrypted file. Furthermore incase of databases, the file itself can contain system, user and publicdata and therefore trying to assign a level of privacy to a file isinappropriate.

An example of a preferred implementation is given by implementation A;each file system is partitioned in 4 types of root directories:

-   -   /system    -   /private/<processsecureid>    -   /resources    -   /others>    -   /system is accessible by the TCB or processes with AUlFiles.        Only the TCB can modify them.    -   /private/<process_secure_id> is available to any process having        their secure identifier assigned to processsecureid as well as        processes that have been granted ‘Root’ or ‘AllFiles’.    -   /resources is public read only, only the Trusted Computing Base        (TCB) can add/remove/modify.    -   <others> is available to any process for file read and write        operations, file creation and deletion.

3.2 Secure Identifier(SID) Concept

As described above, a process can get access to a private directory onlyif its SID matches the name of the private directory. It is notexcluded, in order to support processes with strong coupling, for a setof processes to be given the same SID. In this case, all processes withthe same SID may share the same private directory. However, it has to benoted this concept is very different from the concept of group: oneprocess can have only one SID, it cannot be part of more than onesecurity domain. Therefore the implementation of data caging must stayignorant of the nature of SIDs.

3.3 Software Installer

1. On open devices, at application install time, the structuring of thefile system would be done by the software installer which would depositthe corresponding application files into directories according to therules of the chosen implementation. In implementation A, programs andlibraries complete with their capabilities must be in /system.

2. Any file in a public (read-only or not) directory can be installed

3. Any file in a private directory can be installed if the applicationto install has the same SID as the private directory the file should beput in.

4. Any file in an import directory of a process private directory can beinstalled if the import directory exists. In implementation A, thisimport directory is /private/process_sid/import.

5. No existing files on the device must be overwritten by the package tobe installed if this one has not been identified as an upgrade of theoriginal package that would have created the file. The definition of anupgrade is out of the scope of this invention, as it does not affect theaspects of this invention.

It is important to understand that rule 4) does not run counter to theprinciples of data caging: the installed application will not be able toaccess this file once installed. The presence of an import directory inthe private area of a process notifies the possibility for anotherapplication to make a contribution to this process at install time. Agood example would be a font server all fonts would be stored in theprivate directory of the font server. However external applicationpackages could contribute by adding new fonts without polluting theserver's private directory as they would be all under the importdirectory clearly stating their external origin.

1. A single-user mobile wireless device programmed with a file systemwhich is partitioned into multiple root directories; in which thelocation of a file is enough to fully identify its access policy to aprocess running on the device.
 2. The device of claim 1 in which accessrights of the file are modified by moving its location in the filesystem.
 3. The device of claim 1 in which one of the root directories isreserved to components forming a Trusted Computing Base.
 4. The deviceof claim 1 in which one or more trusted components verify whether or nota process has the required privileges or capabilities to access a filesystem sub-tree.
 5. The device of claim 1 in which a process isrestricted to accessing only its own private area of the file system. 6.The device of claim 5 in which the private area is accessible only to aprocess with a correct secure identifier.
 7. The device of claim 1 inwhich the root directories are each functionally equivalent to thefollowing: (a) a root directory with sub-trees accessible to any processthat has been granted operating system privileges over all files; (b) aroot directory with sub-trees accessible only to a process with acorrect secure identifier; (c) a root directory with sub-trees that arepublic read-only, (d) a root directory with sub-trees that are availableto any process for file read and write operations, file creation anddeletion.
 8. A single user operating system for a mobile wirelessdevice, the operating system comprising a file insulation mechanism thatmaintains the integrity of an exiting file system by controlling wherefiles are installed, the file system being portioned into multiple rootdirectories; in which the location of a file is enough to fully identifyits access policy to a process running on the device.
 9. The operatingsystem of claim 8 in which access rights of the file are modified bymoving it location in the file system.
 10. The operating system of claim8 in which one of the root directories is reserved to components forminga Trusted Computing Base.
 11. The operating system of claim 8 in whichone or more trusted components verify whether or not a process has therequired privileges or capabilities to access a file system sub-tree.12. The operating system of claim 8 in which a process is restricted toaccessing only its own private area of the file system.
 13. Theoperating system of claim 12 in which the private area is accessibleonly to a process with a correct secure identifier.
 14. The operatingsystem of claim 8 in which the file installation mechanism allowsprogram to contribute to another program's private are withoutcompromising it.
 15. The operating system of claim 8 in which the rootdirectories are each functionally equivalent to the following. (a) aroot directory with sub-trees accessible to any process that has beengranted operating system privileges over all files; (b) a root directorywith sub-trees accessible only to a process with a correct secureidentifier; (c) a root directory with sub-trees that are publicread-only; (d) a root directory with sub-trees that are available to anyprocess for file read and write operations, file creation and deletion.